home *** CD-ROM | disk | FTP | other *** search
/ Night Owl 9 / Night Owl CD-ROM (NOPV9) (Night Owl Publisher) (1993).ISO / 011a / bgrunb03.zip / BGRUN.TXT < prev    next >
Text File  |  1993-05-08  |  9KB  |  200 lines
  1. BGRUN 1.0 BETA 03  SAT 08 MAY 93
  2. --------------------------------
  3.  
  4. Remember, please test this on local phone calls before attempting long
  5. distance connects.  Please report all problems/suggestions to E02/758.
  6.  
  7. 1. THIS IS BGRUN-002!  BGRUN-001 (Beta 1 and Beta 2) are not compatible
  8.    with Beta 3.  If a Beta 1/2 copy tries talking to a Beta 3 copy, they will
  9.    immediately hang up.
  10.  
  11. 2. Made BGRUN <-> BGRUN connections a little more reliable.  Every now and
  12.    then, BGRUN would think the other end wasn't running BGRUN and would
  13.    disconnect.  Now, only the MDRIVER "I'm ready" character (^F, "") will
  14.    cause BGRUN to assume the other end isn't running BGRUN.
  15.  
  16. 3. Protocol improved somewhat.  If both ends have nothing to deliver,
  17.    HS/LINK will not be run, saving about 4-5 seconds of connect time.  Maybe
  18.    in the future we may want to switch to the MCI fax plan, i.e., where long
  19.    distance connects are based on 6-second intervals rather than 1-minute
  20.    intervals.
  21.  
  22. 4. Beta 2 was doing something very nasty.  C-files and F-files were being
  23.    sent along with g-bags and b-bags.  WHOOPS!  Fixed.
  24.  
  25. 5. Protocol now reports number of kilobytes awaiting to be sent before the
  26.    actual transfer begins.  While not supported now, IN THE FUTURE, I will
  27.    probably make an option so that if the number of kilobytes to be delivered
  28.    exceeds the disk space left on the remote end, that the transfer will abort
  29.    before it begins, so that mail isn't lost by accident with MDIST.
  30.  
  31. 6. More protocol changes.  Now, both system's dates and times are sent to
  32.    one another for curiosities sake.  Again, while not supported now, IN THE
  33.    FUTURE, I may make it possible for systems to "sync" their clocks off other
  34.    systems (much in the same way PC-LANs can do it).  Also, I plan on checking
  35.    to see if the other system's clock is equal to 1-1-80 and if so, reject the
  36.    remote so we don't get mail corruption.  (Maybe in beta 4).
  37.  
  38. 7. The number of connectable systems via the BGRUN.CNF file has been
  39.    increased from 10 to 100.  I don't think anyone will need any more than
  40.    that, but if you do for some reason, let me know.
  41.  
  42. 8. MBAGGERed file requests ARE NOW SUPPORTED!!!
  43.  
  44. I forgot to mention before, BGRUN has been compiled under Turbo Pascal 7.0.
  45.  
  46. BGRUN 1.0 BETA 02  THU 06 MAY 93
  47. --------------------------------
  48.  
  49. I was informed shortly after the release of Beta 1, some MDRIVER calls were
  50. not able to correctly pass through BGRUN /H in the GTCRASH.BAT file.  Had
  51. something to do with a "{crash}" string, which I have seen before somewhere
  52. in the past, but I have been unable to duplicate it with MDRIVER-38,
  53. MDRIVER-48 or MDRIVER-50.  I don't know if their is a MDRIVER in between
  54. that does crash calls differently or what.  Anyway, when BGRUN is now run
  55. in Host mode, it will timeout if it receives no MDRIVER (^V) or BGRUN sync
  56. character within 1.5 seconds, which will then exit with an errorlevel 1,
  57. which should run MDRIVER in your GTCRASH.BAT file.
  58.  
  59. I forgot to mention last time, I'm trying out some new com routines I found
  60. that allow 16550A FIFO mode.
  61.  
  62. Also, as promised, the config format has changed slightly to allow for more
  63. digits in the phone number.  Remember the pipes are fixed, so a maximum of
  64. 14 characters is allowed in the phone number (and 20 characters in the
  65. password, I don't think I mentioned that last time).  See the included
  66. sample CNF file.
  67.  
  68. PLEASE though, test BGRUN on local systems before attempting long distance
  69. phone calls.  I want to make sure everything is stable first
  70.  
  71. Let me know how BGRUN is working, and whether its something people want, or
  72. if I should drop it before I get too carried away. 
  73.  
  74. BGRUN 1.0 BETA 01  WED 05 MAY 93
  75. --------------------------------
  76.  
  77. A new program to beta test for GT Network sysops.  Taking a break from
  78. BGQWK and finals for a while, I needed to do something to relieve some
  79. stress.  So, I decided to write a faster "MDRIVER".  The name of this may
  80. change, as, just a few hours ago was known as "BGQCQ".  The name originally
  81. assigned to the program when I first came up with the idea in April 1990.
  82.  
  83.     MOVE 100K OF G-BAGS IN LESS THAN ONE MINUTE OF CONNECT TIME!!!
  84.  
  85. First, you need to make sure you have a copy of HSLINK.EXE.  The latest
  86. version is HS120.ZIP.  DSZ is not supported.
  87.  
  88. This program is NOT a replacement for MDRIVER and it is NOT directly
  89. compatible with MDRIVER.  This program is used for making "crash" calls.
  90.  
  91. Your GTCRASH.BAT should look something like this:
  92.  
  93. @echo off
  94. bgrun /h
  95. if errorlevel 2 goto dist
  96. if errorlevel 1 goto paul
  97. goto end
  98. :paul
  99. mdriver xxxx-yyyy etc....
  100. :dist
  101. mdist etc....
  102. :end
  103.  
  104. What's that do?  Well, if a person calls you with MDRIVER, BGRUN will
  105. notice the MDRIVER-sync control (^V) and exit with an errorlevel 1.  Then,
  106. MDRIVER will take the crash call as normal.
  107.  
  108. Now, if BGRUN notices the BGRUN-sync control, it will take the call.  It
  109. will verify the remote CRC, password, and then immediately shell to HSLINK
  110. so that G-bags are sent and received AT THE SAME TIME!  You can get
  111. anywhere from 2600-2800 cps on a standard v.32bis modem!  (Note: You do not
  112. want to make calls in any kind of HST-moduation.  Use only CCITT protocol!)
  113.  
  114. BGRUN is designed only to run on v.32 and v.32bis modems (or 2400 modems
  115. that offer some kind of port locking, but not your average 2400 modem.)
  116.  
  117. Before you can do anything though, you need to make a BGRUN.CNF file.  Here
  118. is a sample file that I use:  (Put this in your GTPATH directory!)
  119.  
  120. 2
  121. 19200
  122. AT
  123. ATDT
  124. H:
  125. 001/040
  126. xxxx-yyyy
  127. 001/070 | 774-7877 | SHINTOM
  128. 001/940 | 893-9124 | CaseSensitive
  129.   
  130. The first six lines must be in that order.
  131.  
  132. 1st line: Com port
  133. 2nd line: Locked DTE rate
  134. 3rd line: Modem init string (for outbound calls)
  135. 4th line: Modem dial string
  136. 5th line: Netmail drive letter and "colon"
  137. 6th line: Net/node in xxx/yyy format (padded with zeros!)
  138. 7th line: GT Netmail CRC in xxxx-yyyy format
  139.  
  140. For now, you can only list ten systems.  I have two above.  The pipes must
  141. remain fixed.  That only gives you eight characters for the phone number,
  142. so you can't make long-distance crash calls with BGRUN yet.  I want to make
  143. sure everything is stable for local calls first before expanding the width
  144. of the field.  Remeber net/nodes must be in expanded format, padded with
  145. zeros.  1/56 is must be noted as 001/056 in the file.  After the second
  146. pipe, we have the passwords for that node.  They are case sensitive.  A
  147. password must be used, it can not be omitted.  Both systems (remote and
  148. host must have an entry for each other in their BGRUN.CNF files).
  149.  
  150. Well, the only other thing is this: To make a crash call with BGRUN, put
  151. the net/node (in full format, padded with zeros) as the first thing on the
  152. command line.
  153.  
  154. BGRUN 001/070
  155. will cause BGRUN to crash 001/070.
  156.  
  157. BGRUN /H
  158. means this copy of BGRUN is acting as the "host" and should only appear in
  159. the GTCRASH.BAT.
  160.  
  161. How fast is BGRUN?  Here is a sample log file (BGRUN.LOG in your GTPATH):
  162.  
  163. 05-05-93 17:13:31  INCOMING BGRUN CALL
  164. 05-05-93 17:13:31    REMOTE 001/070  BGRUN-001  SN 01993
  165. 05-05-93 17:13:38    DISCONNECT
  166. 05-05-93 17:13:38    NO FILE TRANSFER
  167. 05-05-93 17:13:38  END SESSION
  168.  
  169. In the above sample, 001/070 called 001/940 (me, the host).  BGRUN took the
  170. call at 5:13:31 and, no files to deliver, ended at 5:13:38 seconds.  That
  171. was only 7 seconds!  Please note BGRUN-host only started counting after all
  172. the CQs were received, etc.  So, you can add about 7 more seconds to it,
  173. so, the call lasted only 15 seconds, more or less.
  174.  
  175. 05-05-93 16:27:55  001/070 CONNECT 14400/ARQ [B=000 T=001]
  176. 05-05-93 16:28:03    HOST 001/070  BGRUN-001  SN 01993
  177. 05-05-93 16:28:46    DISCONNECT
  178. 05-05-93 16:28:46      UL: Z0001070.001
  179. h    466 38400 bps   79 cps   0 errors     0  466 H:\MAILOUT\Z0001070.001 0
  180. 05-05-93 16:28:47      DL: G0006940.001
  181. H  48539 38400 bps 1609 cps   0 errors     0 3483 H:\MAILWORK\G0001940.001 0
  182. 05-05-93 16:28:47      UL: G0001070.001
  183. h  48498 38400 bps 1471 cps   0 errors 15434 3442 H:\MAILOUT\G0001070.001 0
  184. 05-05-93 16:28:47  END SESSION
  185.  
  186. Now, this example shows some stuff happening.  Here, I called 001/070 from
  187. my machine.  The CONNECT came at 4:27:55.  BGRUN had successfully
  188. identified me at 4:28:03 (this means it took about 8 seconds for GT to
  189. receive all the CQs and run BGRUN, then, handshake, compare CRCs, password,
  190. IDs, etc.)  Now, I sent two files to 001/070 (about 50K worth) and 001/070
  191. sent me another 48K worth (at the same time with HS/Link).  And the line
  192. was disconnected at 4:28:46.  SO, we moved about 100K of G-Bags from
  193. 4:27:55 to 4:28:46.  THAT'S LESS THAN ONE MINUTE!!!  It probably made it at
  194. right about exactly 1 minute when you take into account the v.32bis mating
  195. tones that CCITT protocol makes before "CONNECT"ing.
  196.  
  197. After Beta 1 is tested for a while and assumed stable for local connects, I
  198. will allow it to use long distance connects in Beta 2.
  199.  
  200.